Skip to content

Conversation

@InovelliUSA
Copy link
Contributor

Check all that apply

Type of Change

  • WWST Certification Request
    • If this is your first time contributing code:
      • I have reviewed the README.md file
      • I have reviewed the CODE_OF_CONDUCT.md file
      • I have signed the CLA
    • I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com
  • Bug fix
  • New feature
  • Refactor

Checklist

  • I have performed a self-review of my code
  • I have commented my code in hard-to-understand areas
  • I have verified my changes by testing with a device or have communicated a plan for testing
  • I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change

Summary of Completed Tests

@github-actions
Copy link

Duplicate profile check: Passed - no duplicate profiles detected.

@github-actions
Copy link

@github-actions
Copy link

github-actions bot commented Aug 29, 2025

Test Results

   71 files    462 suites   0s ⏱️
2 399 tests 2 399 ✅ 0 💤 0 ❌
4 069 runs  4 069 ✅ 0 💤 0 ❌

Results for commit 4742d35.

♻️ This comment has been updated with latest results.

@github-actions
Copy link

github-actions bot commented Aug 29, 2025

File Coverage
All files 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/inovelli-2-channel-smart-plug/init.lua 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/qubino-switches/init.lua 85%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/inovelli-LED/init.lua 93%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/multi-metering-switch/init.lua 93%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/aeotec-smart-switch/init.lua 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/preferences.lua 99%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/init.lua 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/configurations.lua 99%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/eaton-5-scene-keypad/init.lua 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/aeotec-heavy-duty/init.lua 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/zwave-dual-switch/init.lua 95%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/qubino-switches/qubino-relays/qubino-flush-1d-relay/init.lua 83%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/qubino-switches/qubino-relays/qubino-flush-2-relay/init.lua 97%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/fibaro-wall-plug-us/init.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/zooz-power-strip/init.lua 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/inovelli-vzw32-sn/init.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zwave-switch/src/qubino-switches/qubino-relays/init.lua 84%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 4742d35

@greens greens changed the title Inovelli VZW32-SN: Adding support for this device for the WWST program WWSTCERT-8357/8360 Inovelli VZW32-SN: Adding support for this device for the WWST program Oct 16, 2025
Comment on lines 9 to 14
- id: colorTemperature
version: 1
config:
values:
- key: "colorTemperature.value"
range: [ 2700, 6500 ]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can now simply define the range your bulb supports in code using the colorTemperatureRange attribute.

Example: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/main/drivers/SmartThings/matter-switch/src/generic_handlers/attribute_handlers.lua#L221

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@greens
Should I do something like this during device initialization then?

device:emit_event(capabilities.colorTemperature.colorTemperatureRange({ value = {minimum = 2700, maximum = 6500} }))
device:emit_event(capabilities.colorTemperature.colorTemperature(6500))

Then, should I change the profile to rgbw-bulb.yml and take out the config section?

Comment on lines 17 to 18
- id: firmwareUpdate
version: 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you're not emitting any events using this capability, please omit it.

If we do add OTA support for z-wave in the future, we will handle adding it to device profiles as necessary.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove this capability.

Copy link
Contributor

@greens greens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a significant number of unit tests. We like our unit test code coverage to be >90%. Yours is currently at 32%.

@InovelliUSA
Copy link
Contributor Author

Please add a significant number of unit tests. We like our unit test code coverage to be >90%. Yours is currently at 32%.

For some reason I can't get my unit tests to work. It is like they aren't loading the driver at all. I'm getting 0/7 for example, but the driver works perfectly in practice and through the certification test suite.

Unit test failures in C:\SmartThingsEdgeDrivers\drivers\SmartThings\zwave-switch\src\test\test_inovelli_vzw32_sn.lua:
Device should initialize properly on added lifecycle event [line 61]
Switch on command should send Basic Set with ON value [line 84]
Switch off command should send Basic Set with OFF value [line 118]
Switch level command should send SwitchMultilevel Set [line 152]
Color control command should emit events and send configuration [line 186]
Central scene notification should emit button events [line 231]
Refresh capability should request switch level [line 256]

I've spent a few hours on it today and can't get it working. I can try more tomorrow.

@greens
Copy link
Contributor

greens commented Oct 23, 2025

@InovelliUSA that's because there's an implied init before every test. You could add all the expected messages from init to your test_init method.

Alternatively, you could restructure your driver so that the events generated in init occur instead in added, since added will only fire on device add, rather than every time the driver starts.

Comment on lines 200 to 206
local device_init = function(self, device)
if device.network_type ~= st_device.NETWORK_TYPE_CHILD then
device:set_component_to_endpoint_fn(component_to_endpoint)
device:set_endpoint_to_component_fn(endpoint_to_component)
--initialize(device)
end
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should no longer need to override the base driver's init function now (or the endpoint/component mapping functions)

@InovelliUSA
Copy link
Contributor Author

I just noticed my motion sensor isn't initializing for the main device. I thought "refresh" would catch it, but I can add it explicitly on Monday.

@greens
Copy link
Contributor

greens commented Oct 28, 2025

@InovelliUSA our defaults for motion sensor rely on the SENSOR_BINARY command class. The device defined in your test file doesn't support it, so no GET is sent on added. What command class are you using to report motion?

@InovelliUSA
Copy link
Contributor Author

@InovelliUSA our defaults for motion sensor rely on the SENSOR_BINARY command class. The device defined in your test file doesn't support it, so no GET is sent on added. What command class are you using to report motion?

We are using the NOTIFICATION command class.

@greens
Copy link
Contributor

greens commented Oct 29, 2025

@InovelliUSA Then I would suggest overwriting the refresh handler with a new function that first calls device:refresh and then sends a Notification:Get.

@InovelliUSA
Copy link
Contributor Author

@InovelliUSA Then I would suggest overwriting the refresh handler with a new function that first calls device:refresh and then sends a Notification:Get.

Something strange is happening when I do this. The process is working fine on the Zigbee driver, but the Z-wave driver becomes unresponsive when I use "refresh". I have tested a few different variants. Even this one causes the driver to stop responding:

local function refresh_handler(driver, device)
if device.network_type ~= st_device.NETWORK_TYPE_CHILD then
device: refresh()
else
device: refresh()
end
end

I will sometimes this in the logs after some time of hitting the refresh button:

2025-10-29T21:10:35.357313398Z TRACE Z-Wave Switch Found CapabilityCommandDispatcher handler in zwave_switch -> inovelli vzw32-sn handler
2025-10-29T21:10:35.357603273Z TRACE Z-Wave Switch Found CapabilityCommandDispatcher handler in zwave_switch -> inovelli vzw32-sn handler
2025-10-29T21:10:35.358610357Z TRACE Z-Wave Switch Found CapabilityCommandDispatcher handler in zwave_switch -> inovelli vzw32-sn handler
2025-10-29T21:10:35.359023815Z TRACE Z-Wave Switch Found CapabilityCommandDispatcher handler in zwave_switch -> inovelli vzw32-sn handler
2025-10-29T21:10:35.360245523Z TRACE Z-Wave Switch Found CapabilityCommandDispatcher handler in zwave_switch -> inovelli vzw32-sn handler
2025-10-29T21:10:35.360498523Z TRACE Z-Wave Switch Found CapabilityCommandDispatcher handler in zwave_switch -> inovelli vzw32-sn handler
2025-10-29T21:10:35.373764815Z FATAL Z-Wave Switch memory error: not enough memory
2025-10-29T21:10:48.072288810Z TRACE Z-Wave Switch Setup driver zwave_switch with lifecycle handlers:

@greens
Copy link
Contributor

greens commented Oct 30, 2025

@InovelliUSA that was my mistake. Z-Wave and Zigbee handle device:refresh calls in slightly different ways. As you probably guessed, Z-Wave works by emulating a refresh command being sent, hence the infinite recursion and stack overflow.

The fix is to use device:default_refresh() instead.

Also I noticed the same thing with the z-wave version of the vzw-31 that we saw with zigbee, so I'd ask you to consolidate here as well. Good news is that there is already a parent driver: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/tree/main/drivers/SmartThings/zwave-switch/src/inovelli-LED

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants